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I. Abstract 

To date very little effort has been made to provide interoperability between various space agency projects. To 
effectively get to the Moon and beyond systems must interoperate. To provide interoperability, standardization and 
registries of various technologies will be required. These registries will be created as they relate to space flight. 
With the new NASA Moon/Mars initiative, a requirement to standardize and control the naming conventions of very 
disparate systems and technologies is emerging. The need to provide numbering to the many processes, schemas, 
vehicles, robots, space suits and technologies (e.g. versions), to name a few, in the highly complex Constellation 
initiative is imperative. The number of corporations, developer personnel, system interfaces, people interfaces will 
require standardization and registries on a scale not currently envisioned. It w'ould only take one exception (stove 
piped system development) to weaken, if not, destroy interoperability. 

To start, a standardized registry process must be defined that allows many differing engineers, organizations and 
operators the ability to easily access disparate registry information across numerous technological and scientific 
disciplines. Once registries are standardized the need to provide registry support in terms of setup and operations, 
resolution of conflicts between registries and other issues will need to be addressed. Registries should not be 
confused with repositories. No end user data is “stored” in a registry nor is it a configuration control system. 

Once a registry standard is created and approved, the technologies that should be registered must be identified 
and prioritized. In this paper, we will identify and define a registry process that is compatible with the Constellation 
initiative and other non related space activities and organizations. We will then identify and define the various 
technologies that should use a registry to provide interoperability. The first set of technologies will be those that are 
currently in need of expansion namely the assignment of satellite designations and the process which controls 
assignments. Second, we will analyze the technologies currently standardized under the Consultative Committee for 
Space Data Systems (CCSDS) banner. Third, we will analyze the current CCSDS working group and Birds of a 
Feather (BoF) activities to ascertain registry requirements. Lastly, we will identify technologies that are either 
currently under the auspices of another standards body or technologies that are currently not standardized. For 
activities one through three, we will provide the analysis by either discipline or technology with rationale, 
identification and brief description of requirements and precedence. For activity four, we will provide a list of 
current standards bodies e.g. IETF and a list of potential candidates. 

II. Introduction 

T he scope and dynamics of space operations are changing. With the announcement that the USA will return to 
the Moon and eventually to Mars, a new dynamics in space systems and operations is emerging. New 
information based technologies are evolving that will change how we use Information Technology (IT) in future 
space operations. As the Internet evolved, it became clear that registries like the Internet Assigned Number 
Authority (IANA) were necessary to control and provide access to those users, developers and others, who were 
developing the technologies and the users who needed the information that traveled on it. What has made the 
Internet functional is the fact that it is interoperable. All anyone has to do is plug his device into a network and, 
regardless of the functionality of the device; it can communicate to virtually anywhere. The only way to accomplish 
this type of interoperability and control was to establish the IANA registry. This approach over time has proven to 
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be effective. Now as we contemplate what will be required to return to the Moon and on to Mars, questions arise 
concerning current and future technologies that will be required to enable interoperability and what mechanisms will 
be necessary to control them. We know from past experience, that there will be a significant requirement to insure 
unique numbering of space vehicles, satellites, robots and bases. We, the space flight community, must identify and 
implement interoperability and control policies and processes including access methodologies. These must be 
conducive to developer, manager and the general user populations. This conduciveness must be in terms of process, 
ease of access and understanding (lack of complexity). If interoperability is to succeed, it must be understood and 
implemented at all levels. From the highest managers (for policy) to procurement/acquisition personnel (to ensure 
what is bought is interoperable), to the engineers and technicians (who will design and install) and finally to the 
operational personnel (who will operate and maintain this system of systems end to end). To accomplish this 
interoperability some sort of registry process will be required. The scope of registry services described in this paper 
is generally applied to the technologies used in space-based development, systems (terrestrial and extraterrestrial) 
and operations. Technologies that are under an established registry e.g. IANA for the Internet, that may have 
application to space systems will be included. 

However, first within the space operations community there must be a single point for defining and standardizing 
registries. The definitions of the registries, how to organize and operate them, and how they interrelate must be 
focused within one recognized authority. Multiple registries of the same technologies would not enable 
interoperability but would discourage it, making unique numbering difficult if not impossible. Imagine the chaos of 
employing two independent registries for assigning spacecraft IDs that use the same or integrated transport 
mechanisms! 

In this paper we will recommend an approach to resolve this situation. We will list and briefly describe; the 
technologies currently being used publicly and within the space community that are already supported by a registry 
e.g. the Spacecraft Identifier, the CCSDS operational standards to ascertain applicability to registries, within the 
current CCSDS working groups potential areas where registry services could be applied. We will look at publicly 
available technologies that may be applied to future space based systems not currently used in space systems. 

III. Interoperability 

A simple definition for interoperability from a dictionary.com website states that interoperability is the ability of 
software and hardware on multiple machines from multiple vendors to communicate. Taking the definition a little 
further and putting it in terms of the current problem, one can think of interoperability as the ability of having 
multiple systems of different types to exchange and use resources and information with little or no prior knowledge 
of each other’s systems. Interoperability problems might not be a big concern in a small environment with a single 
control center or remote investigator site, but as future space operations grow and span across many different 
elements, it is easy to see how quickly interoperability could become an issue. One way to attack this problem is to 
require each control center to be designed exactly the same way. This would insure interoperability between the 
control centers but it may be a hard sell to the overall user community that may have a different design concept for 
their control center. Aside from hurting innovation, this may also be viewed as a hostile form of network 
dictatorship. A better approach to this problem would involve registering the control center data interface. This 
would allow anyone in the user community to search the registry to see how the control center data interface is 
defined. Now the remote user has the freedom to design his or her control center however they want without having 
to know the full design behind the original control center. Registries would play a key role in helping define the 
interfaces between these elements and could eventually take the place of Interface Control Documents (ICD) that are 
used to define how an element will need to design its interface to be able to communicate between elements. This 
would eliminate the need for multiple documents with each center, international entity, and remote investigator or 
developer community member. 


IV. Define the Problem 

Currently there are no standards or processes to manage and control spaceflight related technologies. Granted 
there are many registries and standards organizations that exist to address specific areas but these areas are not 
related to spaceflight. To enable interoperability one aspect for success will be (he ability to access specific 
standards and controls during design, implementation and operations. 

Unique numbering will be required in all facets of space based operations ranging from frame identification 
associated with specific spacecraft, proximity communications between spacecraft and between ground elements 
and spacecraft. These unique number requirements will range from spacecraft identification, applications, processes 



to individual information schemas e.g. XML. Within the space operations community since its inception, each 
project or program generally developed all the necessary systems specifically for their use (fulfilling their specific 
requirements) without recognizing that interoperability between disparate systems and operations would be 
necessary. Until the Space Station was implemented this was not a serious concern especially when using 
expendable vehicles. Today with shrinking budgets, it is beneficial to reuse hardware and software, to be able to 
develop and interact with other systems and applications without significant knowledge of those systems and 
applications, and do so in very short time frames e.g. minutes, hours or days. 

Specifically, how registries could help with future space operations is in the management of Space Craft 
Identifiers (SCID). A SCID is an eight to ten bit binary field that is tied to the link layer protocol and helps identify 
which telemetry stream is associated with a particular spacecraft or spacecraft subsystem. There will be an 
increasing amount of hardware and vehicles being flown in support of manned and unmanned missions to explore 
our solar system. A redesigned SCID registry could take control of this assignment authority and help manage the 
need to assign these SCID and eliminate the need to reclaim them for reuse after a mission is over. There could be 
safety and operational issues associated with reuse of previously assigned numbers, if numbering of specific 
schemas, applications and processes is involved. 

Specifically, unique number of space vehicles, rovers, satellites, robots, space suits will be required well beyond 
what can be numbered under the present numbering scheme. As Table 1 indicates under the internationally 
recognized CCSDS the number of SCIDs ranges from 256 to 1024 numbers with approximately one half of these 
assigned to existing spacecraft. This leaves approximately 500 unique numbers unassigned. While the process 
allows reassignment of numbers after a program has ended, it is estimated by the authors that only 250 or so 
numbers are available for assignment to any major effort to return to the Moon and on to Mars. There are estimates 
that more than 60,000 unique assignments will be required for spacecraft IDs to go to the Moon and on to Mars. 
These assignments may be required for transport over RF systems, for assigning unique application numbers and for 
assigning and registering XML schemas. 

Also some technologies have a large scale impact as far as implementation is concerned. New technologies are 
continually being introduced and current technologies are continually evolving. Without a registry to help keep 
track of these evolving technologies, developers could be wasting a lot of time reinventing solutions to problems 
that other developers have already solved. This situation cannot continue into the future because going back to the 
Moon and then on to Mars will require significant interoperability at the hardware, software, service and operational 
levels. Currently with some minor exceptions there are no specifications, mechanisms, processes or guidelines in 
place that can enable this type of interoperability. A few examples of technologies that could benefit from a registry 
will be covered in a different section of this paper. 


Address 

TM Space 
Data Link 
Protocol 

TC Space 
Data Link 
Protocol 

AOS Space 
Data Link 
Protocol 

Proximity-1 
Space Link 
Protocol 

Transfer Frame 
Version Number 
(TFVN) 

Always 1 
(binary 
encoded 
number is 00) 

Always 1 
(binary 
encoded 
number is 00) 

Always 2 
(binary 
encoded 
number is 01) 

Always 3 
(binary 
encoded 
number is 10) 

Spacecraft 
Identifier (SCID) 

0 to 1023 

0 to 1023 

0 to 255 

0 to 1023 

Virtual Channel 
Identifier (VCID) 

Qto7 

0 to 63 

0to63 

0. 1 

Multiplexer 
Access Point 
identifier (MAP 
ID) 

N/A 

0to63 

N/A 

N/A 

Port Identifier 

N/A 

N/A 

N/A 

0to7 


Table 1, CCSDS Space Link Protocol Unique Identifiers by Protocol 4 




V. The Solution 

The CCSDS is an international organization made up of most space agencies world wide. The CCSDS is 
mandated to provide standards under the International Organization for Standardization. Figure 2 shows the CCSDS 
organization chart, and the list of member and observers agencies and organizations is in Appendix A. Under the 
CCSDS charter, the Space Assigned Numbers Authority (SANA) is to provide unique numbering to the space 
operations community. Figure 1 provides a breakdown of the SANA. Within CCSDS it states in section 4. 1.3.6 
Space Assigned Numbers Authority (SANA) “The core registrar for the CMC’s activities is the SANA. Many 
space mission protocols require that someone keep track of key protocol numbering assignments that were added 
after the protocol came out. Typical examples of the kinds of registries needed are for SCIDs, protocol version 
numbers, reserved Application Process Identifiers, and Standard Formatted Data Units (SFDU) Control Authorities. 
The SANA provides this key configuration management service for CCSDS. The CCSDS Management Council 
(CMC) approves the organization that will act as the SANA. Its public interface is focused through Web-based 
services provided by the Secretariat.” 


Space = 

Space flight activities (flight 
and ground) 

Assigned = 

Registry(ies) 

Numbers = 

Numbering scheme(s) 

Authority = 

Controlling processes and 
organizations 


Figure 1, the Space Assigned Numbers Authority Definition Overview 


The “Space” in SANA indicates the scope of the SANA which includes spaceflight activities both on the ground and 
in flight. There are many types of spacecraft and their integrated technologies that could possibly be provided 
unique numbers. The scope of SANA is all spaceflight activities that cross international boundaries. Included 
would be existing public registries that are applicable to spaceflight that could be approached to assign/manage 



Figure 2, CCSDS Organizational Structure 5 


unique numbering of spaceflight activities under their established purview. The SANA would provide the standards 
and mechanisms to identify and standardize registries that would assign unique numbering to various aspects of 
spaceflight activities including but not limited to Earth based centers and remote terrestrial locations, vehicles, space 
objects, robots, satellites and bases (manned and unmanned, small and large) and potentially systems, applications 
and processes. The SANA should addresses public registries that support spaceflight e.g. IANA. A registry process 
may register ownership of hardware, formats, numbers software applications, XML schemas, especially where they 
cross system, program and/or national boundaries. 

The ’’Assigned” in SANA requires a mechanism to provide numbering and infers a registry process of some sort. 
Numbering can be assigned by a registering process in a hierarchical registry of registries that assigns standardized 
control and process to the registry processes and its contents. It could assign and recognize ownership to the sub- 
registry process and identify ownership and control that can be publicized. A registry process could provide the 
registration process for numbers associated with very general or very detailed level of specifics, objective 
associations, e.g. spacecraft (stuff you can kick) and subjective type associations, e.g. XML schemas (stuff you 
cannot kick). 

The ’’Numbers” in SANA, refers to a standardized numbering scheme for all unique identification numbering 
approaches. The SANA needs to address various spaceflight activities that require numbering, operational situations 
that affect numbering, e.g. when two registered independent objects are mated, and other situations like age, use, 
conflicts and efficiencies e.g. number abbreviations, standards for formats, and schemas. The SANA must 
accomplish all of this while avoiding conflicts in numbering schemes throughout the space community. 

Finally, the “Authority” in SANA, is who is in control and by what authorization for each registry. A Registry 
of Registries (RoR) is required to accomplish this implementation that will provide a single point for registry 
standardization and control. Figure 3 depicts how a RoR and the sub-registries would be related. A standard for the 
RoR and sub-registries would be established and the standards would apply to all sub-registries as guidelines . Also, 
individual sub-registry control authority would be resident in the “registered owner” of the sub-registry. The control 
authority for the RoR would be the CCSDS, and for sub-registries the individual agencies, programs/projects under 
which the sub-registry is registered. Sub-registries may be as simple as a pointer to another registry and a 
standardized control authority (CA) much like the CA in place today, but adjusted for the anticipated increased 
volume and technical diversity. Where necessary, an adjustment to the CA guidelines for specific sub-registries 
may be required. 



Figure 3, Registry of Registries layout 


The RoR is a concept of a place to define ownership, control and access. Access to registry information is 
critical for interoperability where access by implemented, operators and managers is crucial. Therefore it must be 
able to conduct indexing of many registries and potentially pointing to the repositories associated with those 
registries. Under a RoR a centralized control point would be established for multiple participants to access and 
locate information and resources, which will provide dynamic resource integration. Having a registry of registries is 
necessary and essential to accomplish this. A goal is to have an entry portal into a registry of registries, which will 
be the single, authoritative access point to all other registries. The registry of registries would allow for a conductive 





search across the whole scope of registries. Figure 4 shows the registry of registries layout depicting a split between 
space organizations and public sector registry organizations. The top block in the RoR would act as the portal into 
the registry of registries and the sub registries below. Below the RoR, embedded in sub-registries, would be 
registries for any number of registered technologies such as the SCID, interface control definitions and XML 
schemas. 

As Figure 5 depicts, Spacecraft IDs and its control authority would be controlled as it is today by CCSDS, but 
through a newly defined approach and process. Potentially a new approach to numbering based on future 
requirements should be developed. Through the CCSDS standards development process new numbering and control 
authority approaches and procedures could be developed. 

Between the RoR and the sub-registries, a process for coordination, control and problem resolution will be 
required as depicted in Figure 6. There will undoubtedly be coordination needed between the RoR and sub- 
registries in instances of defining scopes, procedures and contacts. Control issues will be resolved through this 
process. Any problems arising during implementation and operations will need to be resolved. As shown, two 
existing registry requirements are XML schemas and asynchronous messaging. 



Figure 4, Registry of Registries Breakdown by Space Organizations and the Public Sector 
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Figure 5, Registry of Registries Spacecraft IDs and Control Authority 
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Figure 6, Registry of Registries Process and Examples 



Figure 7, the Public Sector Depiction 
VI. What to Register 

The question always arises concerning what to register when we discuss registries. Generally speaking, 
technologies that have a common and broad application across agencies, systems, applications, technologies and 
domains may benefit from a registry. This is especially true when they need unique identification. This will include 
technologies or systems that have multiple agencies and contractors involved in development. There are four 
categories, which need to be either investigated for registry requirements or assessed for possible adjustment. These 
categories follow the CCSDS organization process since CCSDS is the only international standards body dealing 
| with space data transport. The four categories are: 

Category one (1) is current CCSDS registries, namely SCIDs and SFDU CA. 

Category two (2) is the set of protocol identifiers, assigned numbers, port numbers and reserved APIDs that are 
currently documented within CCSDS approved documents and SCPS protocol numbers including other current 
deployments like SLE service providers. This would include existing elements e.g. glossary, ground data 
systems and acronym lists. 

Category three (3) is the list of current CCSDS working groups e.g. SM&C, XML schema and namespaces, and 
birds of a feather that may require registries and also includes current CCSDS developments. 

Category four (4) is the catch all for all other activities which may possess a registries requirement, e.g. 
information models, reference software, but currently do not fall under CCSDS and/or do not currently operate 
under a registry. 

The technologies in these categories will be looked at a little closer in this section. One item that may not seem 
to have much significant impact but tends to be a big problem at NASA is the use and reuse of acronyms. A registry 
of acronyms would help prevent a project from using an acronym that is already in use. This would ensure proper 
communication between different projects and or centers by ensuring that acronyms are indeed unique. As 
discussed earlier the SANA registry could take control of a redesigned SCIDs registry to help enforce SCID 
distributions. Message Bus software would be another technology to consider for a registry. This would handle the 
types of messages published on the message bus. A developer could then make use of the registry to see which 
messages that their application could subscribe or publish to the message bus. The IANA could designate a large 


group of IP addresses for the SANA to maintain for spaceflight use or IANA could manage them for SANA. It is 
easy to see as the deep space network evolves and more elements such as satellites, repeaters, spacecraft elements 
are added to the network that IP addresses will need to be assigned to this growing number of elements. A registry 
would be a good way for a user to see what IP address is assigned to a specific element that he/she needs to 
communicate with. With Ipv6 on the horizon this will become even more important for a registry to control these 
new IP addresses for space elements. XML schema, which addresses certain commands or telemetry, could be kept 
in a registry. Users wanting to develop tools to make use of these types of commands and telemetry would be able 
to access the registry and see what format of XML schema to use. This would make interoperability much easier 
since all users would be required to use the same schema for certain commands and telemetry. Without this type of 
registry there would be no easy way to prevent multiple users from developing their own unique XML schemas for 
the same telemetry and commands making interoperability between tools much less certain. 


VII. Registry Information Access 

There must be easy access by operations and development personnel to registry information. Obviously current 
technology is adequate to facilitate broad access. Depending on the technology and the responsible registry 
authority, it is anticipated that access will be via a single authoritative access point which either possess the 
information or points to it. It should be pointed out that the registries described in this paper will not contain user 
data e.g. act as a repository or archive. There can be many implementations for the access but one that holds 
promise is to create a portal for entry into a registry of registries. From this portal all registered information with 
regards to space operations would be available. Across the top tabs of the portal would be the disciplines for 
instance ground control systems - commanding management, telemetry management. If a user chooses command 
management then all associated registry information would be presented. Along the side would be lists of services 
available to the specific choice made in this case Command Management. These services could range from those 
available to anyone like voice and video conferencing to very discipline specific authoritative information like 
navigation registries. One of the main benefits is that everything presented in the portal is authoritative. The ideal 
setup is to configure a registry of registries that will allow one to be able to locate, get details about, and make use of 
any resource located in our registry through structured metadata. In this registry configuration, there will be four 
important components: a full searchable registry, local searchable registry, local publishing registry, and a registry 
of registries. Of course, standards and protocols must be defined so that different registry services will be able to 
interoperate. Therefore, the architecture and organization of the registry must allow all others to have access. Two 
important standards that will help define the registry are interface specification and XML schemas. The interface 
specification is the agreement amongst different parties for defining the search interface. XML schemas formally 
define the various resource types and allow incoming and outgoing messages to be automatically verified for 
correctness of content and structure. XML and its related technologies will be a great choice for protocol. Not only 
is XML a standard way of formatting information, but it also provides XML parsers, namespaces and schemas. 
Registry commands will provide an interface to manage the registry files. Our registry setup does not have to be a 
Service Oriented Architecture (SOA)-based service registry. But a SOA can provide some advantages. SOAs are 
frameworks for reusability. 


VII I. Management and Control 

Overall management and control of the registry process should not be resident in any single national entity but 
should be controlled with broad international involvement. Currently there is only one organization that traverses 
and involves most civilian national space agencies. This is the CCSDS. This organization has been in existence for 
well over 25 years. It has a management structure that enables involvement on the international level. Figure 1 
above shows the organizational structure of CCSDS and a list of member and observer agencies are in Appendix A. 

The CCSDS uses working groups staffed by personnel from the various member agencies. Birds of a Feather 
(BoFs) are precursors to working groups. A BoF defines the charter, estimated resources and schedule for a 
working group. After the CESG and CMC review, and if approved, then a working group is formed. The subject, 
as the list indicates, varies widely. Appendix B lists the current CCSDS working groups and birds of a feather. 

IX. Conclusion 

The SANA will provide a registry service that will greatly enhance current and future space operations. The 
amount of services that will be needed to get back to the Moon and eventually Mars will be very extensive. The 
SANA will provide a means to register these services and control the use of these services. 
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X. Appendix A, List of CCSDS Member and Observer Organizations 6 
Member Agencies 

- Agenzia Spaziale Italiana (ASI)/Italy. 

- British National Space Centre (BNSC)/United Kingdom. 

- Canadian Space Agency (CSA)/Canada. 

- Centre National d'Etudes Spatiales (CNES)/France. 

- Deutsches Zentrum fur Luft- und Raumfahrt e.V. (DLR)/Germany. 

- European Space Agency (ESA)/Europe. 

- Russian Federal Space Agency (FSA)/Russian Federation. 

- Institute Nacional de Pesquisas Espaciais (INPE)/Brazil. 

- Japan Aerospace Exploration Agency (JAXA)/Japan 

- National Aeronautics and Space Administration (NASA)AJSA. 

Observer Agencies 

- Austrian Space Agency (AS A)/ Austria. 

- Central Research Institute of Machine Building (TsNIIMash)/Russian Federation. 

- Centro Tecnico Aeroespacial (CTA)/Brazil. 

- Chinese Academy of Space Technology (CAST)/China. 

- Commonwealth Scientific and Industrial Research Organization (CSIRO)/ Australia. 

- Communications Research Laboratory (CRL)/Japan. 

- Danish Space Research Institute (DSRI)/Denmark. 

- European Organization for the Exploitation of Meteorological Satellites 
(EUMETSAT)/Europe. 

- European Telecommunications Satellite Organization (EUTELSAT)/Europe. 

- Federal Service of Scientific, Technical & Cultural Affairs (FSST&CA)/Belgium. 

- Hellenic National Space Committee (HNSC)/Greece. 

- Indian Space Research Organization (ISRO)/India. 

- Institute of Space and Astronautical Science (ISAS)/Japan. 

- Institute of Space Research (IKI)/Russian Federation. 

- KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary. 

- MIKOMTEK: CSIR (CSIR)/Republic of South Africa. 

- Korea Aerospace Research Institute (KARI)/Korea. 

- Ministry of Communications (MOC)/Israel. 

-National Oceanic & Atmospheric Administration (NOAA)/USA. 

-National Space Program Office (NSPO)/Taipei. 

- Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan. 

- Swedish Space Corporation (SSC)/Sweden. 

- United States Geological Survey (USGS)/USA 



XL Appendix B, List of CCSDS Working Groups (WG) and Birds of a Feather (BoFs ) 7 

System Architecture WG 
Information Architecture WG 
Security WG 

Space Assigned Numbers Authority WG 
Space/Ground Interoperability Architecture BoF 
XML Standards & Guidelines SIG 
Delta-DOR SIG 
Data Archive Ingestion WG 
Navigation WG 

Information packaging & Registries WG 

Spacecraft Monitoring and Control WG 

Reference Model & Concept WG 

Service Management WG 

Cross Support Transfer Service WG 

Onboard Bus LAN WG 

Time Critical Onboard Network Services WG 

Time Critical Onboard Application Services WG 

Onboard Plug and Play BoF 

Onboard Transducer System BoF 

Wireless BoF 

RF Modulation WG 

Space Link Coding and Synchronization WG 

Data Compression WG 

Space Link Protocols WG 

Telecommand Channel Coding WG 

Ranging WG 

Proximity- 1, Build-2 WG 

High Rate Uplink WG 

Long Erasure Codes BoF 

CFDP Interoperability Testing WG 

Packet Protocol WG 

Cislunar WG 

Asynchronous Message Service WG 
IP over CCSDS Space Links WG 
Mars Communication Profile BoF 
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♦ Scope and dynamics of spaceflight are changing 
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♦ Interoperability as it applies to spaceflight systems 
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Current CCSDS Space Data Link Protocol 
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General Definition of Registries 
WRT Space Systems and Operations and What They are Not 
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What are Space Assigned Numbers? 

♦ What is a unique identifier: a string of alpha/numeric 


O) 

c 

■ 

0 o 

CD 0 
CD =3 
cr 

0 ■;= 


CD 


"O 

0 


0 

E 


o 

CD 0 
+* 0 > 
■o 0 )° 

CD 0 0 

£= >- D) 

.^DJC 
CO C CD 
CO 'jr -C 
CD jj> O 

£ CO O 

0 — c 

IS o 

P 0 ^ 

— -^0 
0 0 £ 
> £ *- 
0 c ^ 

— o CD 

0 JO 

0 .9 

o 


o 

T 3 


co 


03 

O 

Q. 

Q_ 

03 

O 


CO 

>> 

if) 


if) u 
•5 | 

if) Cl 
CD ® 

o 
03 
Q. 
if) 

w\ 

if) 

0 
if) 

03 
_Q 

2 

0 o 


D) 

0 


0 Q- "0 


c 

0 

o 

■H 

if) 

O 

_Q 

O 

L_ 

■X 

O % 

T 3 CD 
0 O 

C S 

CD Cl 
■— CO 
0 

0 

< * 


0 
o 
0 . 
Q. 
if) 


0 

E 


0 

> 

o 

TD 

C 

0 

0 

Q. 

O 

0 

E 


0 

0 

&— 

S - E 

o "D 


O 


if) 13 
if) *- 

2^ 

O £ 


0 

0 

0 


if) 

T3 

C 

0 

E 

E 

o 

o 

"O 

c= 

0 

O 

0 

■g 

> 

o' 

- m F\ 
0 § 
f,— ^ 


^ if) 0 
C 0 _r^ 

O if) ^ 

C if) 

C q = 

Eo s 
o 2 > 
O Q. 5 

^ o 

^ X 


0 

;g 

E 

0 

0 

s-_ 

0 


0 

E 

a) 

0 


♦ Data identifier for recording and archiving 

♦ Identify specific XML schemas, messages 

♦ Identify specific application functions within a spacecraft 

Spaceops PRESENTATION 

Kelvin,f.nichols@nasa.qov 256-544-0795 


Space Assigned Numbers Authority 

♦ Scope: Various aspects of spaceflight activities including 








Space Assigned Numbers Authority 

♦ What: Standardized numbering scheme for ail numbering 





Space Assigned Numbers Authority 

♦ The authority is who is in control and by what authorization 
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Overall Description 

Standard(s) required: for creating, maintaining, controlling and operating the RoR and sub-registries 
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Categories of Ownership, Maintenance and Control 

A sub-registry is a standalone registry registered with the RoR 




Four Categories to be considered for registries 

♦ Category 1 : Current CCSDS Registries and control authorities 
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Category One Example 



Category Two Example 




Category Three Example 




Category Four Example 
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Conclusion 



Implement a Registry of Registries under CCSDS 










